Merge duplicate dependencies via link elements#2097
Conversation
Duplicate dependencies are normally merged already in `extract_depends_from_node()`. However, that only works for dependencies that are declared with the same filename. If a link element is in a dependency list, merging may still be required but can be done only after the link element has been loaded. The element state updates don't work correctly if there are duplicate dependencies that aren't merged. Fixes #2002.
This is a regression test for #2002.
juergbi
requested review from
BenjaminSchubert,
abderrahim,
cs-shadow and
gtristan
as code owners
|
Will #2002 occur only if there are 2 link elements with the same target declared in the same project ? I'm concerned that we are seeing issues with a toplevel project link to a sub-sub-project element, and a (differently named ?) link from a sub-project to the same sub-sub-project element. EDIT: If we have the cross project issue, we can treat that as a separate issue, but it would be good to have clarity and an open issue. |
This is about an element having multiple direct dependencies that resolve to the same element. Either multiple links with the same target or a non-link dependency + a link that points to that non-link dependency. Projects/junctions are not relevant for this issue, as far as I can tell. I can't completely rule out that there is another link element issue in combination with junctions, but I'm not aware of such an issue. |
|
I tested this branch on the real-world project that was hitting #2002 and this has fixed the "element never builds, cannot artifact checkout" issues. I have had a read through the patches and they look sensible to me! |
3 participants
Duplicate dependencies are normally merged already in
extract_depends_from_node(). However, that only works for dependencies that are declared with the same filename. If a link element is in a dependency list, merging may still be required but can be done only after the link element has been loaded.The element state updates don't work correctly if there are duplicate dependencies that aren't merged.
Merging
Dependencyobjects does not adjust thenameorpath. This means that if an element has duplicate dependencies, the name from the first dependency declaration is used. One could argue that we should always use the name of the link target, however, this would break cache keys (viaconfigure_dependencies()) and I can't think of a real problem with the current approach.Fixes #2002.